Application No.: 10/675,994 

Amendments to the Drawings 

The attached sheet replaces the original sheet including Fig. 1. In Fig. 1, the 
destinations/sources of input/output lines of elements 125 and 125 are added. 

Attachment: Replacement Sheet 



10 



Application No,: 10/675,994 

REMARKS 

At the time of the Office Action dated October 3, 2005, claims 1-20 were pending. In 
this Amendment, claims 1, 3, 4, 9-20 have been amended, claim 19 has been canceled, without 
prejudice, and the specification and drawings have also been amended. Care has been exercised 
to avoid the introduction of new matter. Adequate descriptive support for the present 
Amendment should be apparent throughout the originally filed disclosure as, for example, the 
depicted embodiments and related discussion thereof in the written description of the 
specification. 

Oath/Declaration 

The Examiner asserted that the oath or declaration is defective because it does not contain 
signatures for all inventors. In response, Applicants note that the six sets of the declarations 
were filed on October 3, 2003. The six sets of the declarations as a whole contains the signatures 
for all the inventors. Applicants respectfully request the Examiner to review the declarations, 
and clarify the record by acknowledging that the declarations are not defective. Attached are 
copies of the declaration and the stamped post card for the Examiner's review. 

Drawings 

The Examiner has objected to Fig. 1 because the destinations/sources of input/output 
lines attached to element 125 and 126 are not identified. In response, Fig. 1 has been amended to 
clarify the destinations/sources of input/output lines of element 125 and 126. Adequate 
descriptive support for this amendment can be found on, for example, page 16, line 23 to page 17, 
line 7 of the specification. Withdrawal of the objection to the drawings is respectfully solicited. 
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Specification 

The Examiner also objected to the specification. In response, Applicants has submitted a 
Substitute Specification including changes addressing the Examiner's objections (see paragraph 
5, subparagraphs a, c, d and e of the Office Action). The abstract has been amended to eliminate 
the expressions "'unit' by 'unit'" and "constituted by" (see subparagraph b). 

In paragraph 5, subparagraph f of the Office Action, the Examiner requested the 
document "UDF specification 2.2.6.4." and "UDF specification 2.2.6" to be submitted. In 
response, Applicants attach the document regarding "UDF specification 2.2.6.4." and "UDF 
specification 2.2.6" to this Amendment for the Examiner's review. 

Applicants, therefore, respectfully solicit withdrawal of the objection to the specification. 

Claims 1-20 have been rejected under 35 U.S.C. §112, second paragraph. 

The Examiner asserted that the claims are indefinite for failing to particularly point out 
and distinctly claim the subject matter which applicants regard as the invention, and are 
incomplete for omitting essential elements and/or structural cooperative relationship of elements 
(see paragraphs 8 and 9 of the Office Action). 

In response, Applicants have amended claims 1, 3, 4, 9-20 based on the Examiner's 
comments, thereby overcoming the stated bases for the rejection of the claims. Applicants, 
therefore, respectfully solicit withdrawal of the rejection of claims 1-20 under 35 U.S.C. §112, 
second paragraph, and favorable consideration thereof. 
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Claim 19 has been rejected under 35 U.S.C. §101 and under 35 U.S.C. §112, first 
paragraph. 

It is noted that the rejection of claim 19 has been rendered moot by cancellation of the 
claim. Withdrawal of the rejection of claim 19 under 35 U.S.C. §§102 and 1 12, first paragraph is 
respectfully solicited. 



It should, therefore, be apparent that the imposed rejections have been overcome and that 
all pending claims are in condition for immediate allowance. Favorable consideration is, 
therefore, respectfully solicited. 

To the extent necessary, a petition for an extension of time under 37 C.F.R. 1.136 is 
hereby made. Please charge any shortage in fees due in connection with the filing of this paper, 
including extension of time fees, to Deposit Account 500417 and please credit any excess fees to 
such deposit account. 



Conclusion 



Respectfully submitted, 




600 13 m Street, N.W. 
Washington, DC 20005-3096 
Phone: 202.756.8000 AJS:TT 
Facsimile: 202.756.8087 
Date: January 3, 2006 



Please recognize our Customer No. 20277 
as our correspondence address. 



WDC99 1 1 81200-1 .065933.0047 
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Note: Time zones West of Qxandinated Universal Time have negative offsets. For 

example, Eastern Standard Time is -300 minutes; Eastern Daylight Time is -240 
minutes. 

Note: Implementations on systems that support time zones should ifiterpict unspecified 
time zones as Coordinated Universal Time. Although not a leojiiiement, this 
interpretation has the advantage that files generated on systems that do not 
support time zones will always appear to have the same time stamps on systems 
that do support time zones, irrespective of the interpreting system's local time 
zone. 



2.1.5 Entity Identifier 

strartEntitylD{ /* ECMA 167 1/7.4 */" 

"UintS flags; 

char . Identffier[23]; 

char IdentifierSuffix[8]; 

} 

UDF classifies Entity Identifiers into 4 separate types as follows: 

• Domain Entity Identifiers 

• UDE Entity Identifiers 

• Implementation Entity Identifiers 

• Application Entity Identifiers 

The following sections describe the format and use of Entity Identifiers based/upon the 
different types mentioned above. 

2.1.5.1 Uijnt8 Flags 

Self- explanatory. 

isr Shall be set to ZERO. 

2.1.5.2 char Identifier 

Unless stated otherwise in this document this field shall be set to an identifier that 
uniquely identifies the implemmtBtion. This methodology will allow for identification of 
the implementation responsible for creating structures recorded on media interchanged 
between different in^le roeot ations. 
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If an implenuentation updates existing structures on the media written by other 
implementations the l^pAift'ng implementation shall set the Identifier field to a value thai: 
uniquely identifies the updating implementation * 

The following table summarizes the Entity Identifier fields defined in the ECMA 167 
standard and this document and shows to what values they shall be set 



Entity Identifiers 







Primary Volume 


Implementation ID 


. ""Developer ID" 


Implementation 
Identifier Suffix 


Primary Volume 
Descriptor 


Application ID 


""Application ID " 


Application Identifier 
Suffix 


juupjcmeniaiion use 
Volume Descriptor 


jmpiemcnuiTiGu 
Identifier 




UDF Identifier Suffix 


Implementation Use 

vuAumc xj vi ip vox _ 


Implementation ID (in 

. JUipi CIU aiiut- VI Uli use 

field) 


""Developer ID" 


Implementation 
Identifier Suffix 




TmTilemeritoitioTi 111 


""Develooer 2D " 


Impl e^ncntatiou 
Identifier Suffix 


Partition Descriptor 


Partition Contents 


"+NSR03" 


Application Identifier 
Suffix 


Logical Volume 
jp escri.pt or 


Implementation ID 


""Developer ID" 


Implementation 
Identifier Suffix 


logical Volume 
Descriptor 


Domain ID 


"*OSTAUDF 
Compliant" 


DOMAJN.Idcntifier 
Suffix 


Pile Set Dcscriptor 


Domain ID 


"*OSTAUDF 
Compliant 44 


DOMAIN Identifier 
Suffix 


File Identifier 
Descriptor 


Implementation Use 


""Developer ID" 


Implementation 
Identifier Suffix 
(optional) 


File Entry 


Implementation ID 


""Developer ID" 


Implementation 
Identifier Suffix 


Device Specification 
Extended Attribute 


Implementation ID 


""Developer ID" 


Implementation 
Identifier Suffix 


TJDF Jmp lementation 
Use Extended 
Attribute 


Implementation ID 


See 3.3.4 3 


UDF Identifier Suffix 


Non-tJDF 
Implementation Use 
Extended Attribute 


Implementation ID 


""Developer ID" 


Implementation 
Identifier Suffix 


UDF Application Use 
Extended Attribute 


Application ID 


See3J.4.6 


UDF Identifier Suffix 


Wfon-UDF Application 
Use Extended 
Attribute 


Application 3D 


""Application ID" 


Application Identifier 
Suffix 


UDF Unique ID 
Mapping Data 


Implementation ID 


""Developer ID" 


Implementation 
Identifier Suffix 


Power Calibration 
Table Stream" " 


Implementation ID 


""Developer W" 


Implementation 
Identifier Suffix 
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Logical Volume 
Integrity Peserijptor 


Implementation ID 
(in Implementation 
Use field) 




Implementation • 
Identifier Suffix 


Partition Integrity 
Entry 


Implementation ED 


K/A 


N/A 


Virtual faxtitioa Map 


partition "type 
Identifier 


"*UPF Virtual 
I > artitioa' , 


UPp Identifier Suffix 


Virtual Allocation* 
Table • ■ 


Implementation Use* 


"•Developer ID" 


Implementation 
Identifier Suffix 
(optional) 


Sparable Partition 
Map 


Partition Type 
Identifier 


^UDF Sparable 
Partition" 


UDF Identifier Suffix 


Sparing Table 


Sparing Identifier 


"*ttt>F Sparing 
Table** 


UDF Identifier Suffix 



NOTE: Tite value of the Eotify Identifier field is interpreted as a sequence of 
bytes, and not as a dstring specified in CSO. For ease of use the values used by 
UDF for this field are specified in terms of ASCII character strings. Hie actual 
sequence of bytes used for fiic Entity Identifiers defined by UDF are specified in 
section 6.2, 

NOTE: In the ID Value column in the above table "^Application ID " refers to 
an identifier thaltmiquely identifies the writer's apphcanon 

In the ZD Value column in the above table "^Developer ID " refers to an Entity Identifier that 
uniquely identifies the cnirxent irnplernenlahon. The value specified should beused when anew 
descriptor is created Also, the value specified should be used for an existing descriptor when 
anything within the scope of the specified EnthylD field is modified 

NOTE: The value chosen for a "^Developer ID " should contain enough infosanafion 
to identify the company and product name for an implementation For example, a 
company called JEfZ with a UDF product called DataOne might choose "*XYZ 
DataOne " as their developer ID. Also in the suffix of their developer ID they may 
choose to record the current version number of their DataOne product This 
information is extremely helpful when trying to determine which irrplernentation wrote a 
bad structure on a piece of media when multiple products from different companies 
have been recording on the media. 

The Suffix Type rmhimm in the above table defines the format of the suffix to be used with the 
cx>rxespmding Entity Identifier. These different suffix types are defined in the following 
paragraphs. 

NOTE: AH Identifiers defined in this document (appendix 6T) shall be registered by 
OSTA as UDF Identifiers: 
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2.2.4.7 byte PartitionMaps 

For the purpose of interchange partition maps shall be limited to Partition Map type 1, 
except type 2 maps as described in this document (2.2.8 and 2.2.9). 

2.2.5 Unallocated Space Descriptor 

struct UnanocatedSpaceDesc { /* ECMA 1 67 3/1 0.8 */ 

struct tag DescriptorTag; 
Uint32 VolumeDescdptoiSeque^c^Nuinber, 
Uint32 NumberofAUcK^tioixDescriptors; 
extent_ad. AHocatioriDescriptorsQ; 

} . 

This descriptor shall be recorded, even if there is no free volume space. The first 
32768 bytes of the Volume space shall not be used for the recording of ECMA 167 
structures. This area shall not be referenced by the Unallocated Space Descriptor or 
any other ECMA 167 descriptor. 

2.2.6 Logical Volume Integrity Descriptor 

struct Ix>©balVolumeIategiityDesc { . /* ECMA 1 67 3/10. 10*/ 

struct tag DescriptorTag, 
TMestamp RecordingPateAndTime, 
Uint32 * IntegtityType. 
struct extend_ad NexflhtegrilyExtent, 
byte Logical VolumeContentsUse[3 2] , 
XJint32 NumberOffartLtioiis, 
. VhH32 LeiigthQffrnpleTnejifah'onUse, 
Uint32 JVeeSpaceTable U> 

On£32 SizeTableO, 
byte ImplementatxonTJseQ 

} . 

The Logical Volume Integrity Descriptor is a structure that shall be written any time 
the contents of the associated logical Volume is mcAxfieA Through the contents of the 
Logical Volume Integrity Descriptor an implementation can easily answer the 
following useful questions: 

1) Are the contents of the Logical Volume in a consistent state? 

2) When was the last date and time that artything within the Logical Volume was 
'modified? . 

3) What isfbe fotalLogical Volume fiee space in logical blocks? 
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4) What is the total size of the Logical Volume in logical blocks? 



5) What is the next available UniquelD for use within the Lo gical Volume? 

6) Has some other implementation modified the contents of the logical volume 
since the last time that the original implementation which created the logical 
volume, accessed it. 

2.2.6.1 byte JLogicalVoliuneContentsTJse 

See section 3.2.1 for information on the contents of this field 

2.2.6.2 Ulnt32 FreeSpaceTable 

Since most operating systems require that an implementation provide the true tree space 
of a Logical Volume at mount time it is important that these values be maintained for all ' 
non- virtual partitions. Tbe optional value of fflFEFEFFEF, which indicates that the 
amount of available free space is not known, shall not be used for non- virtual partitions. 
Fox virtual partitions" the PreeSpaceTable shall be set toj^FFCTFEFF. 

NOTE: The FreeSpaceTable is guaranteed to be correct only when the Logical 
Volume Jntegrity Descriptor is closed 

2.2.63 Uint32 SizeTable 

" Since most operating sys tems require that an implementation provide the total size of a 
Logical Volume at mount time it is important that these values be maintained for all non- 
virtual partitions. The optional Value of #FFFFFFFF, which indicates that fide partition 
size is not known, shall not be used for nonvirtual partitions. Fox \irtiial partitions the 
SizeTable shall be set to #FFFFKFFF. 

2.2.6.4 byte ImplementationtTse 

The ImplementationUse area for the Logical Volume Jntegrity Descriptor shall be 
structured as follows: 



ImplementationUse format 











0 


32 


Implementation!!} 


EntitylD 


32 


4 ■ 


Number of Piles 


Umf32 


36 


4 


Number of Directories 


U5nf32 


40 


2 


Minimum XJDF Read Revision 


Uintl6 


42 


2 


Minimum XJDF Write Revision 


LHntl6 


44 


2 


Maximum UDF Write Revision 


Uintl6 


46 


?? 


Implementation Use 


bvte 
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Implementation ID - The implementation identifier EntitylD of the 
implementation which last modified anything within the scope of this BntityE). 
The scope of this EntitylD is the Logical Volume Descriptor, and the contents 
of fee associated Logical Volume. This field allows an implementation to identify 
which implementation last modified the contents of a Logical Volume, 

Number of Files - The current number of files in the associated Logical 
Volume. This information is needed by the Macintosh OS. All implementations 
shall maintain this information. NOTE: This value does not include Extended 
Attributes or streams as part of the file count 

Number of Directories - The current number of directories in the associated 
Logical Volume. This information is needed by the Macintosh OS. AH 
ioc^exnentafions shafl maintain this information 

NOTE: The root directory shall be included in the directory count Ihe 
directory count does not include stream directories. 

Minimum UDF Read Revision - Shall indicate the minimum recommended 
revision of the UDF specification that an implementation is required to support 
to successfully be .able to read all potential structures on the media This 
number shall be stored in binary coded decimal format, for example #0150 
would indicate revision 1.50 of the UDF specification. 

Minimum UDF Write Revision - Shall indicate fee minimum revision of tie 
UDF specification that an implementation is required to support to successfully 
. be able to modify all structures on the media Has Dumber shall be stored in 
binary coded decimal format, for example #0150 would indicate revision .1.50 
of the UDF specification 

Maximum UDF Write Revision - Shall indicate die maximum revision of the 
UDF specification, that an implementation that has modified the media has 
supported. An implementation shall update (his field only if it has modified the 

•madia and the level of the UDF Specification it supports 1S "higher than the 

current value of this field. This number shall be stored in binary coded decimal 
format, for example #0150 would indicate revision 1.50 of the UDF 
specification, 

Implementation Use - Contains implementation specific information unique to 

the impl Rmgnterfi tm iHe n f] fie ri by the Bmpl ementa ri rm TP 
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